This invention relates generally to cryptography and, more particularly, to methods and systems for managing electronic information that can be used for verification and authentication such as digital certificates.
Cryptography provides a set of techniques for encoding data and messages such that the data and messages can be stored and transmitted securely. Cryptography can be used to achieve secure communications, even when the transmission media (for example, the Internet) is untrustworthy. Using cryptography, it becomes possible to verify the authenticity and origin of data and messages using evidentiary information such as digital signatures and digital certificates. Management of such evidentiary information can pose significant challenges particularly when the volume of such information becomes large, as will become apparent below. Before discussing problems associated with management of evidentiary information, however, some background information on cryptography in general will be useful in understanding how and where the inventive methods and systems fit.
One aspect of cryptography makes use of so-called public and private key pairs. The key pairs are mathematically related, e.g, derived from extremely large prime numbers, such that it is computationally infeasible to derive one key from the other. In public key cryptography, the public key is made public while the private key is kept private. The private key typically never leaves the machine on which it was generated. Accordingly, when using public key cryptography, the only component that must remain secret is the private key. In public key cryptography, information that is encrypted with one of the public or private keys can only be decrypted with the other of the public or private keys.
FIG. 1 illustrates a computer network that makes use of public and private keys. In the illustrated example, there are two usersxe2x80x94Alice and Bob, that desire to send protected messages to one another. If Bob wishes to send Alice a secure email message, he can encrypt the email message with Alice""s public key. When Alice receives the message, she can decrypt it using her private key. Bob should have access to Alice""s public key because, after all, it is public. If, on the other hand, Alice wishes to send a secure email response to Bob, she can simply encrypt the email message with Bob""s public key and send it to Bob. Since only Bob""s private key can decrypt messages encrypted with Bob""s public key, Alice can be assured that the message is private between her and Bob. In addition to providing privacy, public key cryptography can be used to provide integrity. The notion of a digital signature can be used to sign documents and software.
FIG. 2 illustrates a computer network in which a digital signature is utilized. A digital signature can be produced by passing a file, such as an email message, through a specific one-way hashing algorithm. The hashing algorithm produces a much smaller bit stream, e.g. 128-bits or 160-bits, often termed a message digest. The message digest is a unique value that acts as a fingerprint for the file. Because of the nature of the hashing algorithms, a one-bit change in the message can produce a change in roughly one half of the bits in the message digest. This helps to ensure that the recipient receives the actual file that was sent, and not a modified or altered version as will become apparent below. Once a message digest is created, it can be encrypted using the signer""s private key and attached to the file when it is sent. Thus, in this example, Bob can produce a hash of his email message to Alice to provide a message digest, encrypt the message digest with his private key, and attach the encrypted message digest to the email message as his digital signature. To verify the integrity of the file, the application opening the file on Alice""s end, e.g. Alice""s email program, first uses the same hashing algorithm to produce her own message digest of the file. The application then decrypts the signature attached to the file by using Bob""s public key to recover the original message digest produced when the file was originally signed. The two message digests are then compared by Alice""s software. If any part of the message digests do not match identically, then the contents of the file have been modified or corrupted and cannot be trusted.
FIG. 3 illustrates a computer system in which a session key is used. A session key can be thought of as a secret that is xe2x80x9csharedxe2x80x9d between Alice and Bob.
Specifically, Bob can create a session key and use it to encrypt his email message to Alice. After Bob encrypts the email message with the session key, he can encrypt the session key with Alice""s public key and transmit it to Alice. Alice can then decrypt the session key using her private key. With the decrypted session key, Alice can now decrypt the encrypted email message, run the hash to produce the message digest, and process it as described above.
One problem with the above scenario stems from the fact that someone, other than Bob, could conceivably masquerade as Bob by fraudulently holding out a public key that is represented to be xe2x80x9cBob""s public keyxe2x80x9d. Any messages that are intended for Bob and encrypted with the fraudulent public key, could conceivably then be decrypted with the accompanying private key by a person other than Bob. This person would then have access to information that was intended by the sender only for Bob. To address this, as well as other situations, the notion of a digital certificate is used. Digital certificates can be used both to ensure that Bob""s public key is, in fact, his public key, and to a lesser degree, to ensure that Bob""s private key has not been compromised.
A digital certificate can be thought of as an electronic counterpart of an ID card, such as a driver""s license or passport. The validity of a digital certificate is based on systems similar to those used to issue physical ID cards. Specifically, information, e.g. information from and about Bob, is provided to a trusted public body called a certification authority, such as VeriSign, Inc. The certification authority validates the information and then issues a digital certificate. The digital certificate contains information about who the certificate was issued to, as well as the certification authority that issued it. For example, the digital certificate can contain Bob""s email address, and the company and division he works for, etc. The certificate also contains Bob""s public key. In addition, the certificate contains a digest of the certificate""s contents that is signed with the private key of the certification authority to ensure that the certificate has not been altered or forged. That is, the certification authority first creates a hash of the certificate contents, and then encrypts the hash with its private key. Any application having the public key of the certification authority can decrypt the digest and check it against their own hash. If the digests match up, then the certificate can be trusted. If the digests do not match up, then the certificate cannot be trusted. When it comes to certificates, trust is very important. In the above example, Alice and Bob must both trust the certification authority that issues the certificates.
Certification authorities can have their own certificates that can be used to validate that anything signed by the certification authority is, in fact, authentic. To do this, so-called self-signed certificates are used. Self-signed certificates, also referred to as xe2x80x9croot certificatesxe2x80x9d, are issued and signed by certification authorities. Thus, the self-signed certificates must be trusted as being valid. Additionally, some certification authorities may themselves be certified by a hierarchy of one or more certification authorities. When a digital certificate is used to sign documents and software, this information is stored with the signed item in a verifiable form so that it can be displayed to a user to establish a trust relationship.
FIG. 4 illustrates one process for initially receiving a digital certificate. To begin with, an individual""s software generates a public-private key pair. A certificate request containing the public key and signed with the user""s private key is then sent to a certification authority or certificate server. The private key is maintained on the individual""s machine. After a validation process in which the individual must prove that they are who they claim to be, the certification authority issues a digital certificate. The digital certificate has contents that include user information, public key, an encrypted certificate digest, and an identification of the certification authority that issued the certificate. The digital certificate is then stored by the individual""s software and can then be made public.
When an individual such as Alice wishes to send Bob a message that is encrypted with Bob""s public key, she can do so by using Bob""s certificate (which contains his public key). Alice, or more accurately Alice""s software, should first confirm that Bob""s certificate, and hence public key, is valid. To do this, Alice must first get a copy of Bob""s certificate. This can be done by having Bob send his certificate to Alice via email, through HTTP, or any suitable way. Alice can then store Bob""s certificate in her personal store for future use. Once she has the certificate, as shown in FIG. 5, the first thing that Alice""s software does is to look inside Bob""s certificate to ascertain the certification authority that signed the certificate. Alice""s software then decrypts the certificate digest using the certification authority""s public key. So, for example, assume that VeriSign issues Bob""s certificate. If Alice is using Microsoft""s Internet Explorer (IE), IE can look inside Bob""s certificate and ascertain that VeriSign issued it. IE can then check to see whether it has VeriSign""s certificate loaded. If it does, then it can simply use VeriSign""s public key to decrypt the certificate digest. Alice""s software then makes its own digest of Bob""s certificate using the same hash function that VeriSign used and compares the two digests. If the digests are the same, then Alice knows that (1) noone has tampered with the contents of the certificates, and (2) that the certifying authority (e.g. VeriSign) issued that certificate. Additionally, Alice""s software can check to ensure that Bob""s certificate has not expired by checking the expiration date of the certificate. Further, Alice""s software can make an additional check of a so-called certificate revocation list (CRL). A CRL is simply a list of certificates that have been revoked. A certificate can be revoked, for example, if Bob""s private key gets compromised on his machine. There are also so-called certificate trust lists (CTLs). CTLs are simply lists of trusted entities. As used in this document, the term xe2x80x9ccertificatexe2x80x9d0 will be understood to include, without limitation, certificates, CRLs, and CTLs. Once Alice""s software has ascertained that Bob""s public key is valid, Alice can then use the public key to encrypt messages to Bob.
Many entities, other than individual users such as Alice and Bob can have certificates. For example, a web server can have a certificate. Web server certificates can be used by browsers for Secure Socket Layer (SSL) communication. That is, when a browser connects to a web server (e.g. to make an online purchase), it can use the web server""s certificate to authenticate that the web server is, in fact, who it says it is. A browser or a browser user can have a client authentication certificate. These certificates can be used to verify that the clients are who they say they are. Certificate chains are also possible. For example, VeriSign can issue a certificate to Foo Corporation. Foo Corporation can, in turn, issue certificates to its various departments. The individual departments can then issue certificates to its various employees. An advantage of certificate chains is that all of the entities can verify with VeriSign that the certificates are valid.
As one can imagine, a user site can, over time, collect many certificates. Typically, a site has certificates for the user of the site, and other certificates describing those individuals and entities with whom the user communicates. For each entity, there can be more than one certificate. For each individual certificate, there should be a chain of verifying certificates that provides a trail back to a trusted root certificate. As the number of certificates, CRLs, and CTLs in a user""s collection grows, the organization of those certificates becomes an issue. In the past, separate stores have typically been created to keep different kinds of certificates. For example, and as shown in FIG. 6, there might be separate stores for root certificates, certifying authority certificates, and user certificates. This solution creates a problem because an application might need to search several different stores to find a specific certificate. This can create processing complexities because of the number of places an application might have to look. For example, an application might go to a first store, open it and enumerate all of the certificates. If the certificate of interest is not found, the application might proceed to a second store and repeat the process. The application might have to repeat this process many times before finding the certificate of interest.
FIG. 7 illustrates this process for three different physical stores each of which contains a plurality of certificates. Assume that the rightmost certificate (shaded for clarity) is the certificate of interest for an application. In order to find that particular certificate, the application might first have to separately check each of the first two physical stores. Only when the application checks the last store will it find the certificate of interest. This problem is only compounded as the number of physical stores increases. Having an application separately access each physical store, enumerate the contents, check the contents for the certificate of interest, and proceed to the next physical store if the certificate of interest is not found is not an efficient use of an application""s resources.
Another problem concerns duplicative stores and the inability to share information between stores. Specifically, each user will typically have their own stores to store certificates of interest. Each user""s stores can include a root store for holding root certificates, a certification authority store for holding the certificates of the certification authorities, and an individual store for holding an individual""s selected certificates. Each individual is typically responsible for maintaining their own store or stores. So, for example, each individual has to manage and physically oversee which certificates are placed into their particular stores. This can result in duplication of effort, particularly when different users might want to trust the same root certificates, i.e. maintain the same certificates in their stores. Moreover, memory resources can be undesirably consumed when the same certificates are held in a number of different stores.
Another problem that is associated with certificate stores is the inability of the stores to flexibly meet the needs of its users. Such needs might include the ability to create user-defined stores, manipulate the contents of the stores and the stores themselves, and establish relationships between the stores that improve the economics of store utilization. Specifically, certificate stores are typically isolated stores that might be located on a local machine. These stores do not have contact with, nor are they associated with other stores that might be present on the same local machine. This is not desirable particularly in view of trying to optimize computing resources.
Accordingly, this invention arose out of concerns associated with providing improved methods, systems, and architectures for creating and managing hierarchical storage systems for holding evidentiary objects such as digital certificates.
Hierarchical storage systems for holding objects such as digital certificates that are used for evidentiary purposes, and methods of manipulating such systems are described.
In the described embodiment, a logical store is provided or defined and one or more physical stores are associated with and accessible through the logical store. The physical stores can be located on the same machine or across machine boundaries. Access to the physical stores can take place through the logical store with a single application program call to an appropriate application programming interface. In addition, physical or logical stores can be grouped into collection stores in which an operation on one store of the collection is carried through to all of the physical or logical stores of the collection store.
In another aspect, logical and physical stores are configurable and thus, can be defined and manipulated by a user. For example, in one implementation application programming interfaces are provided that enable a user to operate upon both logical and physical stores. A user, through an application program, can register (add) and unregister (remove) both logical and physical stores, as well as build associations within and amongst the stores. These buildable associations can promote economies, such as sharing, between the stores.
One particular type of association is a context link. A context link enables one evidentiary object in one physical store to get its context from another evidentiary object in another physical store. This obviates the need to keep many different physical copies of the same evidentiary object in many different physical stores. Thus, memory resources are used more efficiently.